A software library generally consists of a collection of subroutines or classes, and contains code and data that provide services to independent application programs. This allows for the data and code to be shared and updated in a modular fashion. A library may be statically linked to a target application, i.e., copied into the application program at compile time. Alternatively, a library may be dynamically linked, meaning that its functions and subroutines is loaded into the application program at the time of loading or executing the application in the underlying system.
The underlying operating system generally contains the necessary linking code (sometimes called a “loader”) to link in the library at the appropriate time. In addition to loading the library from disk to the application program, the loader is also designed to perform memory management functions for adding relevant data from the library into memory. Furthermore, the library generally must rely upon system software (e.g., standard system libraries) to initialize its global variables and global objects during the standard startup procedure of the relevant application, and de-initialize them during the standard shutdown procedure of the application (this is a process generally known as “bootstrapping” the linked application).
As such, existing libraries cannot govern the initialization and de-initialization of their own global variables and objects. Thus, even if the controlling application program is done using the library's global variables/objects, the library cannot effectively release its global variables/objects even when they are no longer needed. It would be advantageous to allow the library to effectively control initialization and de-initialization of its own global variables/objects.
For complete applications which are not delivered as a library or libraries, a similar problem exists. I.e., existing applications cannot control the initialization and de-initialization of their own global variables and objects at will; instead the operating system which loads the applications is also responsible for controlling such initialization and de-initialization of the global variables/objects.
Another problem with existing libraries and applications is that various proprietary information of the software developer (e.g., names of functions, variables, and object classes) is open to inspection by others (e.g., customers). It would be advantageous to scramble various symbols in the library code in an effort to protect such proprietary information. Furthermore, in a library or application, a conflict may arise when a variable or object of the same name is used by another library or application loaded in the same system. Thus, it would be advantageous to rename certain symbols in order to avoid such conflicts in the underlying system.